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1.  INTRODUCTION 


One  of  the  major  problems  in  maintaining  large-scale  software  is  the 
difficulty  of  understanding  the  dynamic  behavior  of  the  software  system.  In 
order  to  gain  a good  understanding  of  the  dynamic  behavior,  it  is  necessary 
to  have  effective  dynamic  monitoring  techniques  which  are  applicable  to 
large-scale  software.  One  approach  is  to  build  self-metric  software  in  which 
the  software  system  has  built  into  itself  the  mechanisms  for  measuring  its 
own  behavior.  However,  the  large  quantity  of  data  collected  must  be  ana- 
lyzed. The  software  can  also  have  these  analysis  mechanisms  built  into  it 
giving  the  software  system  the  capability  of  measuring  and  evaluating  its 
own  behavior.  When  this  evaluation  is  used  to  determine  whether  the  soft- 
ware is  behaving  properly,  the  software  is  called  self -checking  software. 

A software  system  can  be  characterized  as  a collection  of  inter-related 
assumptions  and  decisions  among  modules.  Each  module  makes  assumptions 
about  its  operating  environment.  Based  on  these  assumptions  the  module 
designer  makes  a number  of  decisions  about  the  properties  of  the  module. 

These  decisions  completely  characterize  the  external  behavior  of  the  module. 
They  become  the  properties  expected  of  the  module  by  other  modules  that 
interact  with  it.  Thus,  a module  uses  a collection  of  assumptions  and  makes 
one  or  more  decisions  which  are  in  turn  used  as  assumptions  by  other  modules 
throughout  the  system. 

During  software  modification,  new  errors  are  frequently  introduced  into 
the  system  in  the  following  way.  A modification  is  made  to  program  module 
X which  changes  the  definition  of  a decision  D made  in  that  module.  Think- 
ing that  he  has  made  a complete  and  successful  modification,  the  programmer 
begins  testing  the  new  version.  If  everything  seems  to  function  correctly, 
the  new  version  is  considered  correct  and  put  into  production  usage.  How- 
ever, the  problem  arises  because  some  module  Y contains  code  which  uses 
decision  D as  an  assumption.  D has  been  changed  and  module  Y may  no  longer 
function  properly.  If  the  system  is  large  and  the  modification  relatively 
small,  the  testing  was  probably  not  very  extensive  with  respect  to  complete 
testing.  The  necessary  conditions  for  failure  might  not  have  been  generated, 
or  the  malfunction  might  have  been  so  subtle  that  it  went  undetected  at 
the  time  it  occurred.  In  either  case,  the  new  version  of  the  software  system 
contains  errors  due  to  the  software  modification. 

The  maintenance  programmer  works  under  a serious  handicap.  He  must 
work  without  much  knowledge  of  the  execution  behavior  characteristics  of  the 
various  control  and  data  variables  that  comprise  the  software  system.  When 
looking  at  a particular  block  of  code,  it  is  difficult  to  determine  what 
assumptions  are  used  and  what  decisions  are  made  and  passed  on  to  other  parts 
of  the  system.  If  a decision  is  to  be  changed,  it  is  difficult  to  identify 
all  the  other  blocks  of  code  where  that  decision  is  used  as  an  assumption. 

Significant  progress  is  currently  being  made  in  research  aimed  at  being 
able  to  trace  all  the  possible  decision/assumption  paths  eminating  from  any 
given  block  of  code.  However,  there  is  a need  for  a practical  tool  to  help 
ease  the  burden  on  the  maintenance  programmer.  Dynamic  monitoring  tech- 
niques based  on  the  use  of  assertions  can  provide  that  valuable  tool.  Well 
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formulated  assertions  will  serve  as  explicit  statements  of  many  of  the  execu- 
tion behavior  characteristics  relevant  to  each  block  of  code  in  the  system. 
Assertions  will  also  detect  assumption  violations  introduced  during  incorrect 
modifications  to  the  software  system. 

The  use  of  assertions  was  first  introduced  by  Satterthwaite  [1],  who 
used  the  assertions  to  check  the  truth  of  logical  expressions  in  a program. 

I f an  evaluation  was  false,  the  program  was  forced  to  abnormally  terminate 
and  a post-mortem  analysis  was  initiated.  Stucki  [3]  has  presented  a more 
sophisticated  dynamic  monitoring  scheme  which  has  been  added  to  PET  (Program 
Evaluation  and  Tester)  [2].  Along  with  the  assertions  on  logical  expressions 
used  by  Satterthwaite,  Stucki  included  assertions  on  legal  and  illegal  values 
and  ranges  of  variables.  These  techniques  were  still  designed  primarily  for 
use  on  simple  variables.  Stucki  [4]  later  described  extensions  to  this  lan- 
guage that  makes  it  usable  with  simple  array  structures.  But,  even  these  ex- 
tensions have  several  serious  shortcomings  with  respect  to  monitoring  array 
implementa tions  of  linear  list  data  structures.  The  most  serious  problem  is 
that  the  programmer  can  only  specify  the  range  for  the  index  variable,  but 
not  the  exact  sequence  of  values  the  index  should  take.  Even  this  range  spe- 
cification cannot  be  used  to  its  full  potential  since  it  is  a static  defini- 
tion and  does  not  represent  the  true  dynamic  behavior  of  the  data  structure. 
Finally,  if  several  assertions  are  to  be  made  on  the  same  array,  the  index 
specifications  must  laboriously  be  included  with  each  assertion  statement. 
Recently,  Chow  [5]  has  presented  a method  for  using  past  as  well  as  present 
program  status  in  the  assertions  of  logical  expressions.  While  the  ideas 
presented  are  interesting,  they  are  not  dealing  with  the  monitoring  of  array 
structures . 

In  this  report  we  will  discuss  dynamic  monitoring  with  assertions  and 
how  it  can  be  of  benefit  in  the  software  maintenance  process.  We  will  also 
discuss  the  use  of  an  assertion  language  compared  to  other  possible  alter- 
natives. We  will  then  present  an  advancement  to  the  current  assertion  speci- 
fication techniques  that  enables  dynamic  monitoring  of  most  array- implemented 
linear  list  data  structures.  The  main  feature  of  our  new  techniques  is  the 
ability  to  construct  a loop  around  a group  of  simple  assertions.  With  this 
loop  construct,  the  programmer  can  explicitly  define  the  record  travers.-;1. 
scheme  for  a linear  list  data  structure  implemented  with  either  sequential 
or  linked-list  record  allocation.  Within  the  assertion  loop,  Stucki’ s simple 
logical  expression  and  value  assertions  can  then  be  used  on  the  individual 
array  items  defined  by  the  loop  index. 

We  will  give  a number  of  examples  to  illustrate  how  these  techniques  may 
be  used  in  typical  JOVIAL  tables  and  arrays.  The  example  will  include  vari- 
ous linear  list  data  structures,  and  both  sequential  and  linked-list  alloca- 
tion schemes.  We  will  also  discuss  the  implementation  of  an  assertion  lan- 
guage preprocessor  for  a JOVIAL  system.  As  a demonstration,  we  have  modified 
JAVS  [6-8]  so  that  it  recognizes  and  translates  our  proposed  assertion  con- 
structs. We  will  also  discuss  how  these  techniques  are  applicable  to 
other  high  level  languages. 


2.  ASSERTION  CONCEPTS 


2.1  The  Assumption/Decision  Model 

An  ideal  situation  would  be  to  have  assertions  written  to  verify  all  of 
the  assumptions  made  by  each  of  the  modules  in  this  system.  This  would  pro- 
vide complete  documentation  of  expected  run-time  behavior  as  well  as  a means 
for  each  module  to  check  if  the  outside  environment  is  really  as  it  is 
claimed  to  be.  Some  assumptions,  such  as  legal  values  and  ranges  of  input 
variables,  readily  lend  themselves  to  specification  as  assertions.  However, 
more  complex  assumptions  concerning  large  data  structures  or  relationships 
between  various  variables  may  be  too  complicated  to  be  specified  and  thorough- 
ly verified  In  a run-time  situation. 

In  the  same  manner,  assertions  can  be  included  for  decisions  made  within 
each  module.  This  will  provide  documentation  as  well  as  run-time  verification 
of  correct  implementation  of  each  decision.  If  a decision  is  incorrectly 
implemented,  it  may  be  detected  and  identified  at  virtually  the  location  of 
the  error.  This  will  save  lots  of  debugging  time.  As  with  the  assumptions, 
not  all  of  the  decisions  can  be  easily  formulated  into  simple  assertions. 

More  research  will  be  required  to  determine  what  percentage  of  all  the 
assumptions  and  decisions  can  be  easily  specified  as  dynamic  assertions. 

2. 2 A Software  System  Life  Cycle 

Assertions  should  be  a part  of  the  entire  life  cycle  of  a large  scale 
software  system.  They  should  be  considered  in  the  initial  design  and  coding 
phases  and  will  be  of  useful  service  as  long  as  the  system  is  being  main- 
tained . 

During  the  initial  design  phase  of  the  system,  each  module  designer  must 
identify  the  assumptions  used  and  the  decisions  made  by  his  module.  These 
assumptions  and  decisions  diould  then  be  included  as  assertions  in  the  ini- 
tial version  of  the  coded  module.  From  that  point  on,  the  assertions  will 
serve  as  important  documentation  of  the  expected  execution-time  behavior  char- 
acteristics of  that  module.  The  assertions  included  in  each  module  will 
be  useful  when  testing  the  individual  modules  and  then  the  system  as  a whole. 
They  will  help  detect  and  identify  some  errors  earlier  than  otherwise  might 
be  the  case.  They  may  also  detect  errors  that  would  otherwise  go  unnoticed. 
Thus,  initial  testing  can  be  quicker  and  more  thorough. 

When  the  system  has  been  thoroughly  tested  and  is  ready  for  use  in  the 
field,  it  would  be  recompiled  without  the  assertions.  The  assertions  would 
remain  as  comments  but  they  would  not  be  converted  into  executable  code. 

Thus,  no  space  or  time  overhead  is  added  to  the  production  system. 

When  it  is  necessary  to  perform  a modification  on  the  system,  the  asser- 
tions can  again  play  a very  helpful  role.  Before  attempting  any  changes,  the 
maintenance  programmer  must  thoroughly  examine  the  relevant  modules  and  be- 
come familiar  with  both  their  static  and  dynamic  characteristics.  He  must 
be  aware  of  what  assumptions  are  used  in  the  system.  Well  formulated  asser- 
tions provide  the  needed  documentation. 


But  errors  can  still  be  made.  To  minimize  the  amount  of  damage  done, 
it  is  important  that  these  errors  be  detected  as  early  as  possible.  By 
again  compiling  the  assertions  in  the  related  parts  of  the  system,  the  pro- 
grammer has  a power.'  1 tool  for  detecting  any  abnormal  system  behavior,  some- 
thing that  is  otherwise  very  difficult  to  do.  Errors  that  are  introduced 
into  the  system  during  program  modification  usually  occur  through  the  deci- 
sion/assumption relationship.  A decision  in  one  module  may  get  changed  mak- 
ing the  assumption  used  consistent  with  the  new  decision  from  the  first 
module,  it  may  not  function  correctly.  Thus, errors  ate  introduced  when  the 
second  module  is  left  unchanged  using  an  old  assumption.  The  assumption 
assertion  in  the  problem’s  second  module  would  assist  by  noticing  the  assump- 
tion violation  and  identifying  it  to  the  maintenance  programmer. 

2.3  An  Assertion  Language 

Thus  far,  our  discussion  of  assertions  has  not  been  concerned  with  how 
they  might  be  specified.  For  years,  many  good  programmers  have  included 
input  parameter  checks  in  their  routines  reflecting  a "I  don't  trust  anyone" 
philosophy.  These  first  assertions  were  coded  along  with  the  regular  program 
and  frequently  remained  in  the  finished  product.  This  has  an  adverse  effect 
on  the  space  and  time  efficiency  of  the  completed  software  system.  We  need 
assertions  that  can  always  remain  in  the  source  code,  but  yet  don't  a1 ways 
have  to  be  compiled  or  executed. 

The  simplest  method  to  achieve  this  desired  control  is  to  continue  writ- 
ing the  assertions  in  the  high-level  language  of  the  system,  but  include  a 
special  flag  with  each  statement  to  indicate  that  it  is  part  of  an  assertion. 
Then,  prior  to  compilation  the  specially  flagged  statements  could  be  convert- 
ed to  comments  or  left  as  executable  code  by  a simple  preprocessor. 

A more  sophisticated  approach  involves  the  use  of  a specialized  asser- 
tion language.  There  are  several  reasons  we  feel  that  such  an  approach  is 
desirable.  First,  an  assertion  language  provides  a simple  syntax  that  is 
tailored  to  the  checks  that  must  be  expressed.  The  assertions  can  be  written 
in  a much  more  concise  manner  than  would  otherwise  be  possible.  For  in- 
stance, the  value  assertion  as  defined  by  Stucki  [2]  is  much  simpler  than  the 
equivalent  statements  in  any  high-level  language.  The  programmer  is  also 
spared  from  worrying  with  the  output  that  must  be  generated  if  an  assertion 
violation  occurs.  He  knows  that  for  each  assertion,  the  preprocessor  will 
generate  statements  to  output  a standard-form  violation  message.  Also,  this 
concise,  tailored  format  means  that  each  assertion  statement  is  self-do cumen- 
ting;  it  is  easily  readable  and  readily  stands  apart  from  the  remainder  of 
the  code. 

Second,  an  assertion  language  overcomes  a major  problem  associated  with 
assertions  written  in  the  language  of  the  software  system.  When  assertions 
are  written  in  the  same  language  as  the  total  software  system,  it  is  diffi- 
cult to  maintain  the  desired  separation  between  the  assertions  and  the  re- 
mainder of  the  code.  If  the  statements  that  make  up  an  assertion  are  not 
flagged  as  assertions  promptly  when  they  are  written,  they  will  likely  never 
be  so  flagged.  This  is  because  without  an  indepth  study  of  the  code,  it 
is  usually  quite  difficult  to  determine  if  a statement  is  part  of  an  asser- 
tion or  the  real  program.  More  than  likely,  the  final  program  will  have 
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both  flagged  and  unflagged  assertion  statements.  Then, when  the  assertions 
are  to  be  disabled,  these  unflagged  assertions  may  cause  either  compilation 
errors  or  additional  time-and-space  overhead,  or  both.  An  assertion  lan- 
guage avoids  this  problem;  the  assertions  always  remain  distinctly  separate 
from  the  rest  of  the  code. 

Another  benefit  is  the  ease  with  which  the  programmer  can  control  the 
enabling  of  the  assertions.  In  the  simple  case,  a preprocessor  can  either 
convert  all  the  assertions  to  the  appropriate  high-level  code  or  leave  them 
as  comments  in  that  language.  In  a more  powerful  approach,  the  assertion 
language  could  include  a complex  hierarchy  of  control  giving  the  programmer 
both  compilation  and  execution-time  control  over  the  enabling  of  individual 
assertions  [4]. 

All  these  reasons  for  using  an  assertion  language  basically  come  down  to 
convenience  and  reliability.  They  are  the  same  general  reasons  that  the 
software  is  being  written  in  a high-level  language  instead  of  in  an  assembly 
language.  The  programmer's  time  is  valuable  and  we  can  expect  a more  relia- 
ble product. 

However , there  are  some  drawbacks  to  the  use  of  an  assertion  language. 
First,  a simple  preprocessor  must  be  written  that  will  translate  the  asser- 
tion statements  into  the  desired  high  level  code.  Since  an  assertion  lan- 
guage can  be  kept  simple,  this  does  not  appear  to  be  a serious  problem. 
Secondly,  the  assertion  language  is  less  flexible  than  the  high  level  lan- 
guage that  would  otherwise  be  used.  However,  using  Stucki's  simple  asser- 
tions and  the  advancement  we  propose  in  the  remainder  of  this  report,  we 
feel  that  most  desired  assertions  can  be  easily  stated. 

Overall,  we  feel  that  a powerful  assertion  language  provides  signifi- 
cant benefits  in  the  specification  of  dynamic  assertions. 

3.  ARRAY  DATA  STRUCTURES 

The  array  is  a commonly  used  data  structure,  one  that  is  explicitly 
defined  in  almost  all  high-level  languages.  Yet  current  dynamic  monitoring 
techniques  are  not  usable  with  any  but  the  simplest  array  structures. 

An  array  is  defined  as  a collection  of  homogeneous  items  that  may  all  be 
referenced  by  the  same  name.  Sometimes  these  items  are  merely  elementary 
items  of  the  language.  Yet  frequently  they  are  themselves  collections  of 
other  items  that  are  non-homogeneous  and/or  logically  related  to  each  oher. 
These  latter  collections  are  called  records  though  each  language  seems  ro  have 
its  own  unique  terminology.  Arrays  of  records  are  explicitly  provided  for  in 
JOVIAL  [9],  PASCAL  [101,  PL/l  [11],  ALGOL  68  [12]  and  COBOL  [13]  although 
in  JOVIAL  these  structures,  called  tables , are  only  one-dimensional. 

FORTRAN  [14]  is  a prominent  high-level  language  that  has  no  explicit 
record  structure.  There  are  two  common  techniques  used  to  overcome  this 
deficiency.  The  first  method  is  to  create  a separate  array  for  each  indivi- 
dual item  of  the  record.  The  other  way  is  to  implement  m-dimensional  records 
of  an  n-dimensional  space  using  an  n + m dimensional  array.  Either  way, 
there  is  still  the  logical  concept  of  an  array  of  records. 
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In  general,  we  can  consider  every  array  to  be  an  array  of  records. 

These  records  may  be  elementary  items,  explicitly  defined  record  structures 
or  implicitly  defined  FORTRAN  records.  Thus,  when  specifying  dynamic  asser- 
tions for  arrays,  we  want  to  treat  the  arrays  as  record- oriented  data  struc- 
tures. 

4.  ASSERTION  TECHNIQUES  FOR  LINEAR -LIST  DATA  STRUCTURES 

4 . 1  Record- Oriented  Monitoring 

As  noted  above,  most  of  the  data  structures  explicitly  defined  in  cur- 
rent programming  languages  are  record-oriented  organizations.  We  feel  that 
dynamic  assertion  techniques  for  these  structures  ought  to  represent  this 
record  philosophy. 

There  are  two  things  that  the  programmer  must  define  in  order  to  speci- 
fy dynamic  assertions  for  a record-oriented  structure. 

1)  The  group  of  simple  assertions  that  is  to  be  applied  to  each 
record  in  the  structure. 

2)  A systematic  means  of  accessing  each  record  in  the  structure. 

The  simple  assertions  should  be  those  already  defined  in  the  existing 
language  for  use  with  simple  variables.  A language  construct  must  be  defined 
that  will  have  the  assertions  together  as  a group  that  will  be  applied  to 
each  record.  The  systematic  access  of  records  for  the  general  class  of  all 
data  structures  is  not  a simple  task.  Therefore,  for  the  rest  of  the  report, 
we  will  limit  our  discussion  to  linear  lists,  a class  of  data  structures  in  . 
common  use  in  today's  programming  practices. 


4. 2 Linear  Lists 

A linear  list  is  a set  of  n S 0 nodes  x[l],  x[2], . . . ,x[n]  whose  struc- 
tural properties  essentially  involve  only  the  linear  (one-dimensional)  rela- 
tive positions  of  the  nodes  [12].  Three  special  linear  lists:  stacks,  queues 
and  deques;  allow  deletions,  additions  and  accesses  to  values  only  at  the 
first  or  last  node  of  the  structure.  Typically, these  are  implemented  using 
a sequential  storage  allocation  scheme.  The  more  general  class  of  linear 
lists  allows  additions,  deletions  and  accesses  to  any  node  in  the  list.  Typi- 
cally, some  sort  of  linked  record  allocation  is  used  for  these  more  general 
linear-list  structures.  Methods  for  specifying  systematic  traversal  schemes 
for  both  types  of  allocation  will  be  presented  in  the  following  section. 

4.3  Node -Traversal  Schemes 

To  specify  the  traversal  of  any  data  structure,  three  characteristics  of 
the  traversal  must  be  defined: 

1)  the  first  node  to  look  at 

2)  the  method  for  determining  the  next  node 

3)  the  condition  that  signals  the  end  of  the  traversal. 

As  is  done  within  the  program  itself,  an  index  will  be  used  for  speci- 
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fying  the  desired  elements  of  the  data  structure.  Our  definitions  for  the 
first  and  next  nodes  will  be  values  for  the  controlling  index.  The  termina- 
ting condition  will  be  any  general  Boolean  expression. 

The  traversal  scheme  specification  will  take  the  form  of  a standard 
high-level  program  loop.  The  loop  conditions  will  define  the  sequence  of 
records  to  be  monitored  and  within  the  loop  bounds  will  be  grouped  the  asser- 
tions for  each  record. 

4.3.1  Sequential  Allocation 

If  the  records  are  stored  in  a sequential  manner  in  the  data  structure, 
then  the  range  for  the  index  variable  is  sufficient  to  define  the  traversal. 

J A simple  loop  definition  using  the  range  specification  takes  the  following 

format: 

LOOP( (variable  name))  ((range)) 


END  LOOP 

For  example,  consider  a JOVIAL  table  with  N records  stored  in  sequential  or- 
der starting  in  record  0.  The  following  would  define  the  assertions  loop. 

LOOP  (I)  (0...N-1) 


END  LOOP 

A JOVIAL  assertion  preprocessor  would  generate  the  following  JOVIAL  code  and 
insert  it  into  the  original  source  code. 

FOR  I = 0,  1,  N-l  $ 

BEGIN 


END 

This  type  of  assertion  can  also  be  applied  equally  well  to  software  systems 
written  in  other  languages.  For  instance,  the  assertions  on  a FORTRAN  array 
of  N elements  would  look  very  similar  to  those  written  above  for  the  JOVIAL 
example . 

LOOP  (I)  (1...N) 


END  LOOP 

The  translation  to  FORTRAN  would  then  be  as  follows:  where  STMT  denotes  a 
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unique  FORTRAN  statement  number. 

DO  STMT  I = 1,  N 


STMT  CONTINUE 


4.3.2  Linked  Allocation 

A more  complicated  situation  exists  when  the  records  are  stored  in  a 
linked  manner  scattered  throughout  the  physical  data  structure.  The  initial 
value  for  the  control  index  is  generally  taken  from  a variable  maintained  by 
the  main  program  as  a pointer  to  the  first  record.  The  next  value  for  the 
index  usually  is  taken  from  a link  field  within  the  current  record.  And  the 
terminating  condition  is  stated  as  a Boolean  expression  that  when  evaluated 
true,  denotes  that  the  end  of  the  chain  has  been  reached.  Frequently  this 
condition  is  that  the  link  field  of  the  current  record,  and  subsequently  the 
next  value  of  the  index  variable,  is  an  implementation -dependent  null  pointer 
The  syntax  for  this  loop  definition  is: 

CHAIN  ((index  variable))  INIT  ((arith.  expr.  )) 

NEXT  ((arith.  expr.))  END  ((boolean  expr.)) 


END  CHAIN 

For  example,  consider  a JOVIAL  table  that  contains  a linked  list.  Simple 
item  PTR  contains  the  index  for  the  first  record  in  the  chain.  The  table 
contains  item  LINK  which  provides  the  link  between  records  and  is  -1  in  the 
last  record  of  the  chain.  To  loop  through  this  linked  list,  the  following 
directives  would  be  used. 

CHAIN  (IX)  INIT  (PTR)  NEXT  (LINK($IX$))  END  (IX  EQ  -1) 


END  CHAIN 

The  assertion  preprocessor  would  then  generate  and  insert  the  following 
JOVIAL  source  statements. 

IX  = PTR  $ 

Label . 


IX  = LINK($IX$ ) $ 

IF  NOT  (IX  EQ  -1)  $ 

GOTO  Label  $ 

Label  is  used  to  denote  a preprocessor -generated  label  that  is  unique  to  this 
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loop  expansion.  Again  this  type  of  assertion  is  also  applicable  to  software 
systems  written  in  other  languages.  For  example,  consider  how  the  above 
example  might  look  in  a FORTRAN  system.  The  linked  list  is  stored  in  a 
2-dimensional  array,  LLIST,  with  each  row  being  a record  of  the  logical  struc- 
ture. The  first  element  of  each  row  contains  the  link  to  the  next  logical 
record.  Now  our  assertions  would  look  as  follows. 

CHAIN  (IX)  I NIT  (PTR)  NEXT  (LLIST(IX,1))  END  (IX  .EQ.  0) 


END  CHAIN 

The  preprocessor  might  convert  this  to  FORTRAN  as  indicated 
again  STMT  is  used  to  denote  a uniquely  generated  statement 


IX  = PTR 


STMT  CONTINUE 


below,  where 
number. 


IX  = LLIST(IX.l) 

IF  (.NOT.  (IX  .EQ.  0))  GO  TO  STMT 
4.4  Empty  Data  Structures 

One  important  consideration  that  has  not  yet  been  accounted  for  is  the 
possibility  that  the  data  structures  might  be  empty.  If  that  is  the  case, 
then  the  loop  and  the  assertions  defined  within  the  loop  should  not  be  execut- 
ed. To  handle  this  situation,  an  optional  EMPTY  ((boolean  expr;))  clause  may 
be  appended  to  either  of  the  previously-defined  loop-specification  statements 
as  follows: 

LOOP  ((variable))  ((range))  [EMPTY  ((boolean  expr.))] 

or 

CHAIN  ((variable))  INIT  (...)  NEXT  (...)  END  (...) 

[EMPTY  ((boolean  expr.))] 

A true  evaluation  of  the  Boolean  expression  indicates  that  the  data  structure 
is  empty  and  the  assertions  should  be  skipped.  The  JOVIAL  preprocessor  would 
group  the  whole  assertion  loop  as  a compound  statement  and  precede  it  with 
an  appropriate  IF  statement  as  shown  below: 

IF  NOT  ((boolean  expression))  $ 

BEGIN 

Loop  as  defined  previously 

END 

In  the  two  examples  discussed  in  Sections  4.3.1  and  4.3.2,  the  EMPTY  Boolean 
expressions  might  be  "N  EQ  0"  and  "PTR  EQ  -1". 
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4.5  Examples 


In  this  section,  we  will  show  some  examples  detailing  how  the  assertion 
loops  could  be  used  for  typical  linear-list  structures  and  allocation  schemes. 
At  this  point  we  are  only  concerned  with  the  record- traversal  scheme  and  thus 
will  not  try  to  show  any  specific  assertions. 

4.5.1  Stack  - sequential  allocation 

Consider  a JOVIAL  table,  STACK,  that  contains  a stack  of  records.  The 
stack  is  filled  from  the  bottom  (index  = 0)  up  and  NENT (STACK)  contains  the 
number  of  entries  in  the  stack.  The  loop  and  assertions,  including  an  empty 
I stack  check,  could  be  written  as  follows: 

LOOP  (I)  (0. . .NENT(STACK) -1)  EMPTY  (NENT (STACK)  EQ  0) 
Assertions 
END  LOOP 

The  preprocessor  would  generate  the  following  JOVIAL  code: 

IF  NOT  (NENT (STACK)  EQ  0)  $ 

BEGIN 

FOR  I = 0,  1,  NENT (STACK) -1  $ 

BEGIN 

Assertions 

END 
END 

4.5.2.  Queue  - sequential  allocation 

To  implement  a first-come-f irst-serve  queue,  a large  JOVIAL  table,  QUEUE, 
might  be  used.  Records  are  added  to  one  end  of  the  sequential  list  and  re- 
moved from  the  other.  The  queue  moves  progressively  around  the  fixed  length 
table.  HEAD  is  used  here  to  point  to  the  oldest  record  in  the  queue,  the  one 
that  will  be  serviced  next.  TAIL  points  to  the  next  record  to  be  filled  at 
the  end  of  the  queue.  When  the  queue  is  empty,  HEAD  = TAIL.  QUELEN  is  the 
length  of  the  table. 

Because  of  its  cyclic  nature,  the  queue  is  always  in  one  of  three  possi- 
ble states  as  shown  in  Figure  1.  Because  of  the  difference  of  the  relative 
values  of  HEAD  and  TAIL,  these  three  cases  cannot  all  be  monitored  using  the 
same  assertion-loop  definition.  Instead,  we  will  use  a JOVIAL  IF-EITHER 
statement  to  separate  case  3 from  cases  1 and  2 as  follows: 

IFEITH  HEAD  LQ  TAIL  $ 

BEGIN  "CASES  1 AND  2" 

LOOP  (I)  (HEAD. . .TAIL- 1)  EMPTY  (HEAD  EQ  TAIL) 

Assertions 
END  LOOP 

END  "CASES  1 AND  2" 

ORIF  HEAD  CT  TAIL  $ 

BEGIN  "CASE  3" 


1) 


Empty 

Queue 


t HEAD 
TAIL 


2) 


t TAIL  f HEAD 


Fig.  1.  Queue  Implemented  in  Sequential  Allocation 
(The  shaded  areas  represent  empty  records). 


LOOP  (I)  (HEAD . . .QUELEN  -1) 

Assertions 
END  LOOP 

LOOP  (I)  (0...TAIL  -1) 

Assertions 
END  LOOP 
END  "CASE  3" 

END  "IF  EITHER" 

For  each  of  the  assertion-loop  definitions,  code  similar  to  that  for  the 
stack  in  Section  4.5.1  would  be  generated  by  the  JOVIAL  preprocessor. 

4.5.3  Queue  - linked  list  allocation 

Consider  again  the  queue  in  the  previous  section,  only  this  time  being 
implemented  as  a linked-list  of  records.  Table  item  LINK  is  added  and  pro- 
vides the  proper  linkage  between  the  records.  In  the  last  record,  the  LINK 


t HEAD  t TAIL 
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field  contains  the  value  -1.  HEAD  still  points  at  the  oldest  record,  what  is 
now  the  first  record  in  the  list.  TAIL  points  to  the  most  recent  record 
added  at  the  end  of  the  list,  but  is  no  longer  needed  for  the  monitoring  pro- 
cess. If  the  queue  is  empty,  HEAD  and  TAIL  both  contain  the  value  -1. 

The  monitoring  statements  would  be: 

CHAIN  (IX)  I NIT  (HEAD)  NEXT  (LINK($IX$))  END(IX  EQ  -1) 

EMPTY  ((HEAD  EQ  -1)  AND  (TAIL  EQ  -1)) 

Assertions 
END  CHAIN 


; A JOVIAL  preprocessor  would  generate  the  following  JOVIAL  loop: 


IF  NOT  ((HEAD  EQ  -1)  AND  (TAIL  EQ  -1))  $ 
BEGIN  "NON-EMPTY" 

IX  - HEAD  $ 

Label . 

Assertions 

IX  = LINK($IX$)  $ 

IF  NOT  (IX  EQ  -1)  $ 

GOTO  Label  $ 

END 


4.5.4  Circular  Lists 

If  the  queue  in  Section  4.5.3.  was  to  be  implemented  now  as  a circular 
list,  the  LINK  value  for  the  last  record  would  have  to  point  back  to  the 
first  record  in  the  list.  This  would  cause  a change  to  the  terminating  con- 
dition in  the  loop  definition  as  shown  below: 

CHAIN  (IX)  INIT  (HEAD)  NEXT  (LINK($IX$))  END  (IX  EQ  HEAD) 

EMPTY  (HEAD  EQ  -1) 

It  is  the  circular  list  data  structure  that  dictates  the  use  of  a D0- 
UNTIL  loop  in  the  JOVIAL  expansion  of  the  chain  traversal  definition.  If  a 
DO-WHILE  loop  was  used,  the  terminating  condition  would  be  met  immediately 
after  the  initial  index  value  assignment.  In  this  example,  we  can  see  that 
the  initial  assignment  HEAD-* IX  would  lead  to  a true  evaluation  of  IX  EQ  HEAD 
and  thus  an  exit  from  the  DO-WHILE  loop. 

4.5.5.  Doubly-Linked  List 

To  traverse  the  records  of  a doubly-linked  list,  either  one  of  the 
chains  may  be  followed.  Thus  the  doubly-linked  list  structure  simplifies  into 
either  a linked-list  or  a circular  list  as  far  as  the  dynamic  monitoring  of 
the  record  values  is  concerned. 

A totally  complete  set  of  assertions  on  a doubly-linked  list  should  also 
verify  thee  the  two  chains  are  consistent  with  each  other.  This  would  in- 
volve increased  complexity  in  the  loop  specification  language  as  well  as  in 
the  source  code  generated.  At  the  present  time  however,  the  need  does  not 


12 


seem  to  justify  the  added  overhead  and  complexity  that  would  be  required. 

4.5.6.  Sequential  Variable-Length  Records 

Frequently  variable-length  records  are  stored  sequentially  in  a linear 
array,  usually  with  the  first  word  of  each  record  containing  the  length  of 
the  record  as  shown  in  Figure  2.  Typically  the  array  acts  as  a buffer 


Fig.  2.  Array  Used  as  Buffer  for  Variable-Length  Records 
(The  shaded  areas  represent  empty  space.) 


for  these  records  between  main  memory  and  some  sort  of  secondary  storage 
media. 

Our  chain-traversal  definition  is  flexible  enough  to  be  of  easy  use  with 
this  sort  of  record  organization.  In  the  following  example,  BUFFER  is  a 
linear  array.  As  indicated  above,  the  first  word  of  each  record  contains  the 
length  of  that  record.  Following  the  last  record  is  a 0 to  indicate  the  end 
of  the  list.  The  loop  definition  would  be  written  as  follows. 

CHAIN  (IX)  I NIT  (0)  NEXT  (IX  + BUFFER($IX$) ) END  (BUFFER($IX$ ) EQ  0) 

EMPTY  (BUFFER($0$ ) EQ  0) 

Assertions 

END  CHAIN 

4.6  Multi -dimensional  Linear  Structures 

Until  now  we  have  only  demonstrated  our  assertion  approach  with  1-dimen- 
sional linear  lists.  However,  our  techniques  are  also  applicable  to  the  gen- 
eral class  of  multi-dimensional  linear  structures.  This  is  accomplished  by 
the  use  of  nested  loops,  one  for  each  index  of  the  array.  Then  inside  the 
inner-most  loop,  the  desired  assertions  can  be  written  for  the  individual 
records . 

The  following  examples  illustrate  the  use  of  nested  loops  for  multi- 
dimensional arrays.  In  each  example,  we  will  write  assertions  for  an  N by  M 
array  of  records.  This  array  can  be  viewed  as  a linear  list  of  N linear  lists 
of  M records.  Thus,  what  we  must  do  is  to  specify  the  looping  constructs  for 
each  of  the  two  lists. 

The  simplest  and  most  common  view  of  our  N x M array  would  consider 
both  lists  to  be  of  a sequential  nature.  We  would  write  the  loops  for  such 
an  organization  as  follows; 
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LOOP  (I)  (0...N-1) 

LOOP  (K)  (0...M-1) 

Assertions 
END  LOOP 

END  LOOP 

Another  organization  of  the  array  may  be  considered  as  a sequential 
list  of  linked  lists.  In  this  example,  the  array  HEAD ($0 :N-1$ ) contains  the 
pointer  to  the  head  of  each  of  the  linked  lists.  These  assertion  loops,  now 
using  both  a LOOP  and  a CHAIN,  would  be  written  as  follows: 

LOOP  (I)  (0...N-1) 

CHAIN  (KK)  I NIT  (HEAD  ($1$))  NEXT  (LINK($I ,KK$)) 

END  (KK  EQ  -1) 

Assertions 
END  CHAIN 

END  LOOP 

We  may  also  view  the  array  as  a linked  list  of  linked  lists. 
The  array  LISTLINK  ($0:N-1$)  provides  the  linkages  in  the  list  of  lists  while 
HEAD  ($0:N-1$)  again  contains  the  head  of  list  pointers  for  the  lists  of 
records.  TOP  points  to  the  first  list  of  records. 

CHAIN  (II)  I NIT  (TOP)  NEXT  (LISTLINK($II$) ) END  (II  EQ  -1) 

CHAIN  (KK)  I NIT  (HEAD ($11$))  NEXT  (LINK($II ,KK$ ) ) 

END  (KK  EQ  -1) 

Assertions 
END  CHAIN 

END  CHAIN 

As  demonstrated  in  these  examples,  our  assertion  techniques  are  applicable  to 
any  combination  of  allocation  schemes  that  might  be  used  in  an  array  struc- 
ture. They  are  simple  and  powerful  enough  to  make  assertion  specification 
for  multi-dimensional  linear  structures  a simple  task. 

5.  OPTIONAL  INTEGRITY  CHECKS 

Thus  far,  we  have  discussed  only  integrity  checks  on  the  data  values  con- 
tained in  the  various  linear  data  structures.  ' However,  with  a linked-list 
structure,  it  is  also  important  that  we  are  able  to  check  the  integrity  of  cer- 
tain aspects  of  its  logical  structure.  Toward  this  end,  we  now  define  the  op- 
tional BOUNDS  and  COUNT  clauses  to  be  appended  to  the  chain- traversal  loop 
definition  as  follows: 

CHAIN  ((variable))  INIT  (...)  NEXT  (...)  END  (...) 

[EMPTY  (...)]  [BOUNDS  ( (range  »1  [COUNT  ((range))] 


5. 1 Bounds 

With  this  clause,  the  programmer  can  make  an  assertion  about  the  legal 
values  that  the  index  variable  may  take.  If  the  index  is  out  of  range,  it 
usually  indicates  a serious  error  in  the  logical  data  structure.  For  this 


reason,  after  a BOUNDS  assertion  violation,  the  assertion  loop  should  be 
immediately  exited.  This  feature  should  provide  detection  of  erroneous  link 
field  values  and  data  structures  that  have  simply  overgrown  their  assigned 
memory  space. 

5. 2 Count 

This  clause  specifies  an  assertion  about  the  legal  number  of  records  in 
the  linked  list.  For  instance,  if  the  program  maintains  its  own  record 
count,  this  clause  could  monitor  the  correctness  of  that  count.  Another  easy 
use  might  be  to  verify  that  the  data  structure  is  indeed  empty  or  non-empty 
at  a particular  time.  As  with  the  BOUNDS  clause,  an  error  message  is  printed 
when  an  assertion  violation  is  detected. 

6.  SIMPLE  ASSERTIONS 

In  this  section  we  will  examine  the  actual  assertions  needed  for  simple 
and  record-oriented  items.  Stucki  [4]  has  defined  one  general  and  five  spec- 
ialized local  assertion  formats.  Three  of  these  seem  important  within  the 
framework  of  the  current  discussion. 

1)  ASSERT  ((boolean  expression)) 

2)  ASSERT  VALUE  ((variable  name))  ((list  of  legal  values 
and/or  ranges)) 

3)  ASSERT  VALUE  ((variable  name))  NOT  ((list  of  illegal  values 
and/or  ranges)) 

The  last  two  assertions  could  obviously  be  written  using  one  or  more  of  the 
general  Boolean  expression  assertions.  However,  for  clarity  and  ease  of  use, 
we  feel  that  the  value-type  assertions  should  also  be  explicitly  defined  in 
the  assertion  language. 

A brief  example  should  adequately  illustrate  these  assertions.  Let  us 
again  consider  the  stack  from  Section  4.5.1,  but  this  time  we  are  interested 
in  the  actual  assertions  that  we  skipped  over  previously. 

As  defined  before,  I is  the  index  variable,  and  we  will  use  it  to  iden- 
tify the  record  being  examined.  If  A,  B,  C,  D are  items  defined  in  the 
table,  we  could  see  the  following  assertions  on  these  items. 

ASSERT  (A($I$)  * B($l$)  GT  0) 

ASSERT  VALUE  (C($I$))  (1,  5,  10,... 15) 

ASSERT  VALUE  (D($I$))  NOT  (2,  4) 

It  should  be  noted  here  that  currently  JAVS  [7]  provides  only  the  general 
assertion  on  a Boolean  expression. 

7.  ASSERTION  LANGUAGE  PREPROCESSOR 

In  this  section  we  will  examine  some  of  the  important  issues  in  the 
implementation  of  a preprocessor  for  our  new  assertion  constructs  in  a JOVIAL 
system.  Some  of  these  implementation  issues  can  effect  the  way  the  user  may 
interface  with  the  system.  Our  purpose  here  is  to  present  the  various  alter- 
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natives  that  are  available.  We  will  also  look  at  our  implementation  in  JAVS 
of  the  preprocessor  for  an  assertion  language  with  these  new  constructs. 

7.1  Index  Variables 

Both  of  our  new  looping  constructs  define  the  values  for  an  index  varia- 
ble that  is  used  to  identify  the  desired  array  elements.  Some  of  the  more 
difficult  implementation  issues  revolve  around  these  indices,  and  particular- 
ly, the  way  they  must  be  specified  in  JOVIAL.  One  of  our  main  objectives 
must  be  to  supply  the  user  with  the  simplest  possible  tool.  Yet,  this  objec- 
tive will  certainly  have  to  be  balanced  against  the  realities  of  the  preproc- 
essor implementation. 

7.1.1  Variable  Types 

One  issue  that  is  peculiar  to  JOVIAL  systems  and  was  covered  over  pre- 
viously is  the  matter  of  index  variable  types.  As  the  JOVIAL  expansions  for 
the  LOOP  and  CHAIN  constructs  were  previously  defined,  each  requires  the  use 
of  a different  type  of  variable  for  the  index.  Since  the  LOOP  command  trans- 
lates into  a FOR  statement,  a one  letter  FOR  variable  must  be  used.  On  the 
other  hand,  the  CHAIN  command  requires  the  use  of  a two  to  six  character 
variable.  The  programmer  must  either  remember  which  command  requires  which 
type  of  variable  or  be  aware  of  the  code  to  which  the  commands  are  translated. 
Neither  alternative  is  very  attractive. 

An  alternate  translation  for  the  LOOP  construct  may  provide  the  best 
solution.  Instead  of  using  a FOR  loop,  the  loop  controls  could  be  written 
explicitly  with  other  JOVIAL  structures.  The  translation  for  a LOOP  command 
into  JOVIAL  would  then  be  as  follows: 

LOOP  (IX)  (0...N-1) 


END  LOOP 
translates  to 

IX  = 0 $ 

label. 


• 

IX  = IX  + 1 $ 

IF  NOT  (IX  GR  N-l)$ 

GOTO  LABEL  $ 

The  normal  two-  to  six-character  variable  name  could  then  be  used  for  the 
index  variable  in  both  loop  constructs. 

7.1.2  Interference 

It  is  important  that  the  assertion  statements  not  interfere  with  the 
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normal  execution  of  the  software  system.  The  assertions  must  have  access  to 
all  of  the  main  program's  variables,  yet  they  must  not  be  allowed  to  alter 
the  values  of  those  variables.  The  loop  index  variables  are  the  only  poten- 
tial problem  variables  since  they  are  the  only  ones  to  which  new  values  are 
assigned.  Ideally  the  preprocessor  should  protect  the  main  program  from 
interference  by  these  index  variables.  Otherwise, the  programmer  will  have  to 
be  responsible  for  avoiding  harmful  side  effects  from  his  assertions. 

If  the  target  language  for  the  preprocessor  is  a block-structured  lan- 
guage, such  as  ALGOL  60  [16],  ALGOL  68  [12],  PASCAL  [10]  or  PL/I  [11],  the 
preprocessor  can  easily  protect  the  main  program  from  interference  by  the 
assertions.  This  is  possible  because  of  the  way  these  languages  define  the 
scope  of  the  variables.  Any  variable  x is  considered  to  be  local  to  the  block 
in  which  it  is  defined.  Variable  x can  then  be  accessed  as  a global  variable 
in  blocks  nested  within  the  defining  block  unless  the  nested  block  defines  its 
own  variable  x.  In  that  case,  the  original  x is  unreachable  yet  left  un- 
harmed until  the  lower  block  is  exited.  The  preprocessor  needs  only  to  trans- 
late each  block  of  assertions  into  a block  structure  of  the  target  language. 
Within  this  block  the  index  variable  could  be  declared  and  used  as  a local 
variable.  Thus, the  assertions  have  access  to  all  the  variables  from  higher 
level  blocks,  and  yet  the  index  variable  does  not  interfere  with  any  of  the 
other  variables  already  in  use. 

However,  JOVIAL  does  not  provide  such  facilities.  The  scope  of  a varia- 
ble is  either  the  entire  program  or  routine  in  which  it  is  defined.  Thus, 
to  avoid  interference,  the  index  variable  must  be  unique  relative  to  all  the 
other  currently  live  variables.  One  solution  is  for  the  preprocessor  to 
"guarantee"  this  uniqueness.  It  could  concatenate  a short  string  onto  the 
variable  name  to  create  a new  unique  name.  For  example, the  string  might  be 
XXXX.  Then,  if  the  programmer  used  II  for  the  index  variable  name,  the  pre- 
processor would  generate  the  variable  name  IIXXXX.  This  assumes  that  the 
programmer  knows  to  avoid  using  variable  names  ending  with  the  string  "XXXX". 
This  solution  may  increase  a lot  of  complexity  in  the  preprocessor.  A 
reasonable  alternative  seems  to  be  to  require  the  programmer  to  choose  a 
unique  index  name  for  his  assertions.  A better  approach  may  be  to  always 
use  a particular  distinctive  name,  such  as  ASSTIX,  that  would  never  be  used 
elsewhere  in  the  program. 

7.1.3  Declarations 

In  most  programming  languages,  the  programmer  must  declare  all  of  the 
variables  he  intends  to  use.  Since  the  assertion  loop  indices  are  not  part 
of  the  main  program,  we  feel  that  the  programmer  should  not  need  to  include 
declarations  for  them.  This  means  that  the  preprocessor  must  insert  the 
necessary  declarations. 

In  the  block  structured  language  approach  described  in  the  previous 
section,  the  declaration  responsibility  naturally  falls  on  the  preprocessor. 
Declarations  are  generated  and  inserted  at  the  beginning  of  each  assertion 
block. 

For  a JOVIAL  implementation,  the  situation  is  not  so  well  defined.  If 
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the  preprocessor  is  creating  its  own  names,  then  it  must  also  insert  the  var- 
iable declarations.  However,  if  the  programmer  uses  the  same  index  variable 
name  twice  and  the  preprocessor  includes  two  declarations,  the  compiler  will 
issue  a warning  message.  Certainly  this  does  not  represent  an  ideal  solution 
to  the  problem.  On  the  other  hand,  if  the  programmer  is  responsible  for  using 
unique  index  variable  names,  it  would  seem  natural  for  him  to  also  include 
the  declarations. 

7.1.4  JOVIAL  conclusions 

We  feel  that  both  loop  constructs  should  use  the  same  type  of  index  var- 
iable as  discussed  in  Section  7.1.1.  Regarding  variable  interference  and 
declarations,  a realistic  approach  is  to  leave  the  index  variaole  choice  and 
declaration  responsibilities  with  the  programmer.  These  decisions  provide  an 
adequete  interface  with  the  programmer  while  holding  down  the  complexity  of 
the  preprocessor. 

7 . 2 Integrity  checks 

When  the  COUNT  and  BOUNDS  options  were  previously  introduced,  no  trans- 
lations into  JOVIAL  code  were  given.  The  intent  of  the  two  clauses  was  evi- 
dent without  introducing  the  details  of  implementation.  Here  we  will  discuss 
those  details. 

The  code  for  these  options  must  be  designed  so  that  it  can  be  easily 
inserted  into  the  code  already  specified  for  a CHAIN  loop.  This  will  help 
keep  the  option  translations  a simple  process. 

7.2.1  COUNT 

For  the  count  check  we  will  introduce  a specific  variable,  ASTCNT,  that 
will  hold  the  count  of  records  processed  in  any  particular  loop.  ASTCNT  can 
be  automatically  declared  at  either  the  beginning  of  the  program  or  the  time 
of  the  first  count  check.  The  later  declaration  requires  the  use  of  a separ- 
ate flag  to  indicate  whether  or  not  ASTCNT  has  already  been  declared. 

For  a particular  CCXJNT  check,  the  preprocessor  must  generate  code  to 
initialize,  increment  and  validate  ASTCNT.  Code  must  be  inserted  before,  in 
the  middle  of,  and  after  the  basic  assertion  loop.  For  example, 

CHAIN  (IX)  I NIT  (PTR)  NEXT  (LINK($IX$))  END  (IX  EQ  -1) 

COUNT  (LOW. ..HIGH) 

END  CHAIN 

would  be  translated  to 

ASTCNT  = 0 $ 

IX  = PTR  $ 

LABEL. 

ASTCNT  = ASTCNT  + 1 $ 
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IX  = LINK($IX$)  $ 

IF  NOT  (IX  EQ  -1)  $ 

GOTO  LABEL  $ 

IF  NOT  (LOW  LQ  ASTCNT  LQ  HIGH)  $ "COUNT" 

print  error  message  $ "COUNT" 

The  comment  "COUNT"  indicates  the  statements  that  were  inserted  to  im- 
plement the  COUNT  option. 


7.2.2  BOUNDS 

The  BOUNDS  clause  presents  a slightly  different  problem.  Now, the  valid- 
ity check  must  be  made  within  the  basic  assertion  loop  and  an  exit  taken  if 
a violation  is  detected.  To  provide  the  exit  point,  the  preprocessor  must 
generate  another  unique  variable  name  that  will  be  placed  immediately  follow- 
ing the  normal  loop  exit. 

For  example,  the  following  is  an  assertion  loop  definition  with  a BOUNDS 
check  and  the  generated  JOVIAL  code.  All  statements  inserted  for  the  BOUNDS 
clause  are  so  marked. 

CHAIN  (IX)  I NIT  (PTR)  NEXT  (LINK($IX$))  END  (IX  EQ  -1) 

BOUNDS  (LOW. ..HIGH) 


© 

END  CHAIN 


IX  = PTR  $ 

LABEL. 

IF  NOT  (LCW  LQ  IX  LQ  HIGH)  $ "BOUNDS" 

BEGIN  "BOUNDS" 

print  error  message  $ "BOUNDS" 

GOTO  ELABEL  $ "BOUNDS" 

END  "BOUNDS" 


• 

IX  = LINK($IX$)  $ 

IF  NOT  (IX  EQ  -1)  $ 

GOTO  LABEL  $ 

ELABEL.  "BOUNDS" 


7.2.3  A Complete  Example 

The  following  is  a complete  example  designed  to  show  how  the  code  from 
each  of  the  options;  EMPTY,  COUNT,  and  BOUNDS  fits  together.  The  JOVIAL 
statements  from  each  of  the  options  are  again  marked  with  comments. 


19 


CHAIN  (IX)  INIT  (PTR)  NEXT  (LINK($IX$))  END  (IX  EQ  -1)  EMPTY  (PTR  EQ  -1) 
COUNT  (LOCNT . . .HICNT ) BOUNDS  (LOBND . . .HIBND ) 


END  CHAIN 


IF  NOT  (PTR  EQ  -1)  $ "EMPTY" 

BEGIN 

ASTCNT  = 0 $ "COUNT" 

IX  = PTR  $ 

LABEL. 

IF  NOT  (LOBND  LQ  IX  LQ  HIBND)  $ "BOUNDS" 

BEGIN  "BOUNDS" 

print  error  message  $ "BOUNDS" 

GOTO  ELABEL$  "BOUNDS" 

END  "BOUNDS" 

ASTCNT  = ASTCNT  + 1 $ "COUNT" 


• 

IX  = LINK($IX$ ) $ 

IF  NOT  (IX  EQ  -1)  $ 

GOTO  LABEL  $ 

ELABEL. 

IF  NOT  (LOCNT  LQ  ASTCNT  LQ  HICNT)  $ 
print  error  message  $ 

END 

7.3  Command  Stack 

In  the  definition  of  an  assertion  loop,  all  of  the  loop  parameters  are 
specified  at  the  top  of  the  loop.  Some  of  these  parameters  are  used  imme- 
diately by  the  preprocessor  while  others  must  be  saved  for  usage  at  the  end 
of  the  loop.  As  was  discussed  previously,  assertion  loops  may  be  nested 
several  levels  deep.  This  suggests  the  use  of  a stack  to  retain  the  neces- 
sary information  for  each  of  the  nested  loops.  Each  element  of  the  stack 
should  be  a record  with  fields  for  the  different  parameters  to  be  retained. 
The  following  are  the  parameters  that  must  be  retained  for  a JOVIAL  implemen- 
tation as  we  have  thus  far  described  it. 

1)  Index  variable 

2)  Algebraic  expression  for  the  next  value  of  the  index  variable 

3)  Boolean  condition  that  indicates  exit  from  the  loop 

4)  Label  at  the  head  of  the  loop 

5)  Label  at  the  exit  from  the  loop  (optional  entry-used  with  BOUNDS 
clause) 

6)  Legal  range  for  record  count  (optional  entry-used  with  COUNT  clause) 


"BOUNDS" 

"COUNT" 

"COUNT" 
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7.4  JOVIAL  Automated  Verification  System  (JAVS) 


The  current  version  of  JAVS  provides  the  programmer  with  some  asser- 
tion statements  for  use  with  Boolean  expressions.  We  feel  that  the  in- 
clusion of  our  new  assertion  constructs,  along  with  the  Stucki-like  VALUE 
assertion,  would  make  JAVS  a much  more  powerful  system  development  and  main- 
tenance tool.  Thus,  we  explored  the  feasibility  of  modifying  JAVS  to  this 
means.  First,  it  was  decided  that  the  set  of  directives  recognized  by  JAVS 
could  be  easily  expanded  to  suit  our  needs.  And  just  as  importantly,  it  was 
determined  that  JAVS  already  contained  general  statement  parsing  and  text- 
manipulation  routines  to  facilitate  implementation  of  the  new  directives. 

None  of  the  existing  software  would  need  to  be  changed,  only  new  code  added. 
The  following  sections  briefly  describe  the  modification  work  done  on  JAVS. 
(More  detailed  documentation  and  the  modified  JAVS  source  listing  can  be 
found  in  Appendices  III  and  IV). 

7.4.1  JAVS  Directives 

JAVS  directives  are  statements  which  may  be  included  in  a JOVIAL  source 
text  but  are  only  meaningful  to  the  JAVS  preprocessor.  Some  of  these  direc- 
tives, such  as  JAVSTEXT,  are  used  for  naming  and  organizing  various  parts  of 
a large  software  system.  Others,  the  computational  directives,  cause  JOVIAL 
code  to  be  generated  and  inserted  into  the  probe  text.  It  is  this  subset 
that  we  are  interested  in  expanding. 

All  the  JAVS  directives  are  written  in  the  following  basic  format: 

". (jAVS-directive ) (any  necessary  parameters)" 

with  the  character  strings  ".  and  " serving  as  directive  delimiters.  The 
choice  of  these  symbols  as  delimiters  insures  that  the  directives  can  be  left 
in  the  source  code  and  will  be  interpreted  as  comments  by  the  JOCIT  compiler. 
(Double  quotes  (")  serve  as  the  JOVIAL  comment  delimiter.) 

For  our  new  assertion  constructs,  we  added  these  four  new  JAVS  computa- 
tional directives:  CHAIN,  ENDCHAIN,  LOOP  and  ENDLOOP.  Each  directive  state- 
ment was  given  the  appropriate  syntax  as  defined  previously.  For  instance, 
the  LOOP  directive  syntax  is  as  follows: 

".LOOP  ((variable  name))  ((range))  [EMPTY  ((boolean  expression))] 

We  also  saw  a need  to  expand  the  simple  assertion  power  of  JAVS  as  out- 
lined in  Section  6.0.  In  that  section,  we  defined  the  following  three  formats 
for  simple  assertions. 

ASSERT  ((boolean  expression)) 

ASSERT  VALUE  ((variable  name))  ((list  of  legal  values  and/or  ranges)) 
ASSERT  VALUE  ((variable  name))  NOT  ((list  of  illegal  values  and/or 

ranges )) 

JAVS  already  supports  an  assertion  directive  of  the  following  form 
".ASSERT,  (JOVIAL  boolean  expression)". 

We  decided  to  retain  this  syntax  for  the  expression  assertion  in  or- 

der that  all  old  JOVIAL  software  would  be  upward  compatible  with  the  new  JAVS 
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system.  Then,  for  the  other  two  value  assertions,  we  have  added  a VALUE  dir- 
ective with  the  following  syntax. 

".VALUE  ((variable  name))  [NOT]  ((list  of  values  and/or  ranges))" 

In  summary,  we  made  a total  of  five  additions  to  the  set  of  computation- 
al directives  that  JAVS  recognizes.  Four  of  these  are  to  support  our  new 
assertion  constructs  and  the  fifth  is  an  enhancement  to  the  simple  assertion 
power  of  JAVS.  A complete  listing  of  the  assertion  directives  recognized  by 
the  enhanced  version  of  JAVS  can  be  found  in  Appendix  I. 

7.4.2  Directive  Code  Modifications 

Our  first  task  was  to  make  the  JAVS  source  text  analyzer  recognize  the 
new  directives  that  we  wished  to  add.  This  was  a simple  job.  Procedure  LOOK 
in  component  JAVS-2  contains  a table,  LI,  of  all  the  JAVS  directives.  We  had 
to  increment  the  table  size  by  5 (definition  of  NJDIR)  and  add  entries  for 
the  new  directives  and  their  lengths  to  table  Ll. 

The  remainder  of  the  modifications  had  to  be  made  in  component  JAVS-5, 
the  module  instrumentation  component.  Procedure  PRBDIR  is  the  routine  that 
is  called  each  time  a directive  is  encountered  in  the  instrumentation  phase. 
PRBDIR  had  to  have  additions  made  to  it  so  that  when  any  of  the  five  new  di- 
rectives are  encountered,  it  invokes  the  correct  procedures. 

New  procedures  had  to  be  written  for  the  directives  CHAIN,  ENDCHAIN, 

LOOP  and  VALUE.  Since  we  decided  to  translate  the  LOOP  directive  into  code 
similar  to  that  for  CHAIN  (no  FOR  loop),  we  are  able  to  use  the  ENDCHAIN  pro- 
cedure for  both  the  ENDCHAIN  and  ENDLOOP  directives.  Each  of  these  new  rou- 
tines was  written  in  the  style  of  the  older  directive  routines,  relying 
heavily  on  the  already  existing  support  routines  of  components  JAVS-2,  JAVS-5 
and  JAVS -11. 

The  compool  for  the  JAVS-5  component  also  had  to  be  updated.  Procedure 
templates  were  added  for  each  of  the  new  procedures  and  for  BALPAR,  a JAVS-11 
routine  that  had  not  previously  been  called  from  the  JAVS-5  component.  A 
common  area,  ASSERT,  was  also  added  to  the  compool.  Its  major  contents  are 
the  stack  and  stack  pointer  for  processing  the  assertion  loops.  It  also  con- 
tains a flag,  DCLASSCNT,  which  indicates  whether  or  not  the  variable  ASSCNT 
(used  for  checking  record  count  assertions)  has  yet  been  defined. 

Like  statements  written  in  any  other  language,  it  is  certainly  possible 
for  these  assertion  statements  to  be  incorrectly  written.  For  instance,  the 
NEXT  field  might  be  missing  in  a CHAIN  directive  statement.  Or,  there  might 
be  an  imbalance  between  the  number  of  LOOP  and  ENDLOOP  statements.  Checks 
have  been  included  in  all  the  assertion  procedures  to  detect  these  types  of 
mistakes.  In  the  event  of  such  an  error,  the  JAVS-11  ERROR  procedure  is  in- 
voked with  an  explanatory  message.  Appendix  II  contains  a complete  list  of 
these  error  diagnostic  messages. 

7.4.3  Assertion-Violation  Output 

JAVS  uses  a scheme  based  on  the  JOCIT  compiler's  MONITOR  primitive  for 
outputting  assertion-violation  messages.  This  was  done  to  add  another  level 
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of  user  control  to  the  activation  of  the  assertions.  The  violation  output 
can  be  turned  off  at  compile  time  independent  of  the  output  from  the  JAVS 
structural  instrumentation  [17]. 

To  us,  this  scheme  does  not  seem  entirely  satisfactory.  The  first  prob- 
lem is  that  it  ties  the  assertion  facility  to  the  monitoring  task.  One  can 
never  have  the  assertions  enabled  without  also  having  the  monitors  activated. 
Thus  it  is  not  possible  to  get  any  occasional  assertion  violation  output 
without  also  getting  the  possibly  voluminous  monitor  output.  And  to  make 
matters  even  worse,  output  from  both  sources  goes  to  the  same  output  file. 

However,  the  major  problem  is  that  under  this  scheme,  the  output  mes- 
sages must  be  fixed  at  the  time  of  structural  instrumentation.  It  is  not 
possible  to  output  the  execution -time  values  of  the  pertinent  variables  along 
with  a violation  message.  The  programmer  is  virtually  left  in  the  dark  when 
it  comes  to  locating  the  cause  of  the  violation.  He  is  not  given  even  the 
slightest  bit  of  information  from  which  to  start  his  search. 

We  feel  that  a more  powerful  and  flexible  output  scheme  could  be  used 
by  sacrificing  the  compile- time  control.  Instead  of  using  the  MONITOR  capa- 
bility, standard  JOVIAL  output  statements  could  be  inserted  into  the  probe 
text.  These  statements  would  output  the  appropriate  explanatory  message  and 
any  pertinent  variable  values  for  each  violation. 

However,  in  keeping  with  our  desire  not  to  alter  any  of  the  existing 
JAVS  system,  we  will  retain  the  MONITOR  scheme  for  use  with  our  new  asser- 
tions . 

8.  CONCLUSION 

In  this  report  we  discussed  the  contributions  that  dynamic  monitoring 
can  make  in  the  area  of  software  maintenance.  Assertions  provide  documen- 
tation that  can  help  the  maintenance  programmer  avoid  modification  errors. 

The  assertions  also  assist  in  the  detection  of  any  errors  that  are  intro- 
duced during  modification.  These  benefits  were  previously  not  recognized 
since  the  initial  work  on  dynamic  monitoring  had  been  done  from  a software 
reliability  perspective. 

The  main  thrust  of  the  results  presented  in  this  report  is  the  expansion 
of  the  already  existing  assertion  concepts  to  include  array  data  structures 
which  have  been  virtually  ignored  in  all  previous  work.  Initially  we  devel- 
oped a record- oriented  approach  toward  array  data  structures.  Based  on  this 
approach  we  proposed  an  assertion  technique  that  will  enable  effective  moni- 
toring of  most  linear- list  data  structures  that  have  been  implemented  as 
JAVS  tables  or  arrays.  We  believe  this  is  a big  step  in  the  development  of 
monitoring  as  an  effective  software- development  tool. 

Finally,  we  discussed  some  important  considerations  relative  to  the  im- 
plementation of  our  new  assertion  concepts  for  a JOVIAL  system.  As  demon- 
stration, modifications  were  made  to  JAVS  so  that  it  could  serve  as  the 
preprocessor  for  an  expanded  assertion  language  containing  our  new  constructs. 
Appendix  V contains  the  output  listing  of  an  example  run  of  this  modified 
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version  of  JAVS . 


More  research  is  needed  to  study  the  use  and  benefits  of  dynamic  moni- 
toring throughout  the  whole  software  life  cycle.  We  need  to  determine  how 
easily  assumptions  and  decisions  can  be  defined  and  explicitly  stated  when 
designing  software.  Then,  how  many  of  these  can  effective  assertions  be 
written  for?  Assertions  appear  to  be  a promising  tool  for  detecting  errors 
made  during  software  modification,  but  we  need  to  research  this  area  more. 
We  must  determine  what  kind  of  errors  are  typically  made  and  how  effective 
this  type  of  dynamic  monitoring  will  be  in  detecting  them.  Our  belief  is 
that  dynamic  monitoring  will  indeed  be  an  effective  and  powerful  tool  over 
the  whole  software  life  cycle. 


2U 


I 

' 


i 


/ 


9.  REFERENCES 

[ 1]  Satterthwaite,  E.,  "Debugging  Tools  for  High  Level  Languages,"  Software 
Practice  and  Experience,  Vol.  2,  1972,  pp.  192-217. 

[ 2]  Stucki,  L.  G. , "Automatic  Generation  of  Self-Metric  Software,"  Proceed- 
ings of  1973  IEEE  Symposium  on  Computer  Software  Reliability,  1973, 
pp.  84-100. 

[ 3]  Stucki,  L.  G.  and  Foshee,  G.  L, , "New  Assertion  Concepts  for  Self-Met- 
ric Software  Validation,"  Proceedings  1975  International  Conference  on 
Reliable  Software,  1975,  pp.  59-71. 

[ 4]  Stucki,  L.  G. , "The  Use  of  Dynamic  Assertions  to  Improve  Software  Qual- 
ity," Ph.D.  Dissertation,  UCLA  Graduate  School  of  Engineering,  Computer 
Science  Dept.,  June,  1976. 

[ 5]  Chow,  T.  S.,  "A  Generalized  Assertion  Language,"  Second  International 
Conference  on  Software  Engineering,  1976,  pp.  392-399. 

L 6]  Cannon,  C.,  Brooks,  N.  B.,  and  Urban,  R.  J.,  JAVS  Technical  Report  - 
User's  Guide  (RADC-TR-77-126,  Vol  I - AD  A040103),  General  Research 
Corporation,  Santa  Barbara,  California,  April  1977. 

[ 7]  Cannon,  C.  and  Brooks,  N.  B.,  JAVS  Technical  Report  - Reference  Manual 
(RADC-TR-77-126,  Vol  II  - AD  A040104)),  General  Research  Corporation, 
Santa  Barbara,  California,  April  1977. 

1 8]  Cannon,  C.  and  Brooks,  N.  B.,  JAVS  Technical  Report  - Methodology 
Report  (RADC-TR-77-126,  Vol  III  - AD  A041048) , General  Research 
Corporation,  Santa  Barbara,  California,  April  1977. 

[ 9]  JOCIT  Compiler  Users  Manual,  Computer  Sciences  Corporation  under  con- 
tract F30602-72-C-0467  with  Rome  Air  Development  Center. 

[10]  Jensen,  Kathleen  and  Wirth,  Niklaus,  PASCAL  User  Manual  and  Report, 
Springer-Verlag,  New  York,  1974. 

[11]  Pollack,  S.  V.  and  Sterling,  T.  D. , A Guide  to  PL/l,  Holt,  Rinehart, 
and  Winston,  Inc.,  New  York,  1969. 

[12]  Van  Wijngaarden,  A.,  et.al..  Revised  Report  on  the  Algorithmic  Lang- 
uage Algol  68,  Springer-Verlag,  Berlin,  1976. 

[13]  Dock,  V,  Thomas,  COBOL:  American  National  Standard,  Reston  Publishing 
Company,  Reston,  Virginia,  1973. 

[14]  Pollack,  S.  V.,  A Guide  to  FORTRAN  IV.  Columbia  University  Press,  New 
York,  1965. 


25 


[15]  Knuth,  D.  E.,  The  Art  of  Computer  Programming.  Vol.  1,  Fundamental 
Algorithms,  Addison-Wesley  Publishing  Company,  Reading,  Mass.,  1973. 

[16]  Rutishauser,  Heinz,  ed.,  Description  of  Algol  60.  Springer-Verlag , 

New  York,  1967. 

[17]  Benson,  J.  B. , Brooks,  N.  B. , Gannon,  C.  and  Urban,  R.  J. , JAVS  Compu- 
ter Program  Documentation:  Vol.  1,  System  Design  and  Implementation 
Manual  (CR-2-722),  General  Research  Corporation,  Santa  Barbara,  Calif- 
ornia, November,  1976,  pg.  4-61. 


26 


APPENDIX  I 


JAVS  Assertion  Directives 


".ASSERT,  (boolean  expr.)" 

".VALUE  ((variable  name))  [NOT  3 ((list  of  values  and/or  ranges))" 

".LOOP  ((variable  name))  ((range))  [EMPTY  ((boolean  expr.)) 3 
".ENDLOOP" 

".CHAIN  ((variable  name))  INIT  ((arith.  expr.))  NEXT  ((arith.  expr.))  END 
((boolean  expr.))  [EMPTY  ((boolean  expr .)) 3 [BOUNDS  ((range)) 3 [COUNT 
( (range)) 3" 

".ENDCHAIN" 
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APPENDIX  II 

Error  Diagnostic  Messages 


This  appendix  describes  the  error  diagnostic  messages  that  JAVS  generates 
as  a result  of  improperly  specified  assertion  directives.  The  standard  JAVS 
ERROR  procedure  is  used  to  output  these  messages  to  the  JAVS  output  report. 
Given  here  with  each  error  message  is  a brief  explanation  of  the  probable 
cause  of  the  error  and  in  what  procedure  it  was  detected. 

ASSERTION  STACK  OVERFLOW 

There  is  an  overflow  condition  on  the  assertion  command  stack.  The 
number  of  nested  LOOP  and  CHAIN  directives  exceeds  the  permissable 
limit.  This  limit  is  defined  as  MAXCSTK  (=  10)  in  procedures  PRBCHAIN 
and  PRBLOOP  and  in  common  ASSERT.  Error  detected  in  procedure  PRBCHAIN 
or  PRBLOOP. 

ASSERTION  STACK  UNDERFLOW 

There  is  an  underflow  condition  on  the  assertion  command  stack.  For  the 
ENDLOOP  or  ENDCHAIN  directive  being  processed,  there  has  been  no  match- 
ing LOOP  or  CHAIN  directive.  Error  detected  in  procedure  PRBENDC. 

CHAIN  ASSERTION  ERROR  - NO  INIT  FIELD 

No  INIT  field  specified  for  a CHAIN  assertion  directive.  Error  detected 
in  procedure  PRBCHAIN. 

CHAIN  ASSERTION  ERROR  - NO  NEXT  FIELD 

No  NEXT  field  specified  for  a CHAIN  assertion  directive.  Error  detected 
in  procedure  PRBCHAIN. 

CHAIN  ASSERTION  ERROR  - NO  END  FIELD 

No  END  field  specified  for  a CHAIN  assertion  directive.  Error  detected 
in  procedure  PRBCHAIN. 
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APPENDIX  III 


JAVS  Modification  Documentation 

A.  JOVIAL  Automated  Verification  System 

Documentation  of  changes  made  to  JAVS  to  implement  an  expanded  assertion 
specification  language. 

B.  Work  done  at  Northwestern  University 

by  John  L.  Ramey 
(3  1 2 ) 4 9 2 - 5 248 

Sponsored  by  Rome  Air  Development  Center 
Under  Contract  No.  F3060 2-76-C-0397 
Project  Engineer  - Mr.  R.  Iuorno 

C . Abstract 

This  work  is  a modification  to  JAVS  to  enhance  its  dynamic  assertion 
capabilities.  More  computational  directives  were  added  to  the  set  that 
JAVS  recognizes.  These  new  directives  give  JAVS  more  assertion  power 
both  for  simple  data  items  and  most  linear  list  data  structures.  New 
routines  were  added  to  translate  these  assertions  into  the  proper  JOVIAL 
code  during  the  instrumentation  phase.  All  the  source  code  was  written 
in  JOVIAL  and  tested  on  a HONEYWELL  6180. 

D.  Computer  definition 

The  hardware  requirements  are  the  same  as  for  the  unmodified  JAVS. 

E.  System  Description 

The  modifications  were  run  successfully  under  the  H6180/GCOS  Version 
H.l  operating  system.  No  new  special  executive  software  is  required. 

F.  Program  Description 

The  general  philosophy  used  when  making  the  modifications  was  to  use 
the  same  basic  approaches  to  the  organization  and  coding  as  were  done 
in  the  original  version  of  JAVS.  All  new  routines  were  written  using 
the  same  style  as  the  older  ones  and  previously  written  support  routines 
were  used  whenever  possible.  Only  enhancements  were  made  so  that  all 
previously  written  programs  and  JAVS  directives  still  work  under  the 
modified  version.  As  was  done  with  the  previous  directives,  they  are 
all  recognized  in  the  initial  basic  analysis  of  phase  2.  Then  during 
the  instrumentation  phase,  routine  PRBDIR  distinguishes  between  the 
various  possible  directives  calling  the  correct  routine  to  handle  each. 

JPROBE  - modified  procedure  in  JAVS-5 

An  addition  was  made  to  this  procedure  so  that  it  initialized  both 
the  assertion  command  stack  pointer  (CSTKPTR)  and  the  variable 
indicating  whether  or  not  the  count  variable  had  yet  been  declared 
(DCLASSCNT) . 

LOOK  - modified  procedure  in  JAVS -2 
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Additions  were  made  to  the  directive  table  in  this  procedure  so 
that  the  five  additional  directives  would  be  recognized  during  the 
basic  analysis  phase. 


PRBAST  - modified  procedure  in  JAVS-5 

This  procedure  was  modified  to  make  use  of  the  new  procedure 
PRBDCL  instead  of  doing  the  same  tasks  internally. 

PRBCHAIN  - new  procedure  in  JAVS-5 

This  procedure  handles  the  CHAIN  assertion  directive.  For  each 
directive,  it  generates  the  required  JOVIAL  code  for  the  top  of 
the  assertion  loop  and  saves  the  necessary  information  on  the  top 
of  the  assertion  command  stack  for  use  when  the  matching  ENDCHAIN 
directive  is  encountered. 

PRBCHKL  - new  procedure  in  JAVS-5 

This  procedure  is  used  to  keep  from  overflowing  the  TXTBUF  buffer 
when  building  statements.  Whenever  there  is  a possibility  that  a 
new  addition  might  not  fit  in  the  buffer,  PRBCHKL  is  called  before 
ADDTXT.  If  it  will  not  fit,  the  contents  of  the  buffer  are  written 
out  as  a statement  and  the  buffer  is  cleared. 

PRBDCL  - new  procedure  in  JAVS-5 

This  procedure  makes  sure  that  the  MONITOR  function  is  turned  on 
for  outputting  violations  from  the  assertions. 

PRBDIR  - modified  procedure  in  JAVS-5 

Additional  entries  were  made  to  the  IFEITHER  statement  in  this 
routine  so  that  when  the  new  directives  were  encountered  during 
the  instrumentation  phase,  the  appropriate  procedures  would  be 
called. 

PRBENDC  - new  procedure  in  JAVS-5 

This  procedure  handles  both  the  ENDCHAIN  and  the  ENDLOOP  directives. 
It  gets  the  information  from  the  record  on  top  of  the  assertion 
command  stack  and  generates  the  JOVIAL  statements  necessary  for 
the  termination  of  the  assertion  loop. 

PRBLBL  - new  procedure  in  JAVS-5 

This  procedure  generates  a six-digit  label  based  on  the  current 
statement  number.  Called  by  PRBCHAIN  and  PRBLOOP. 

PRBLOOP  - new  procedure  in  JAVS-5 

This  procedure  handles  the  LOOP  assertion  directive.  For  each 
directive,  it  generates  the  required  JOVIAL  code  for  the  top  of 
the  assertion  loop  and  saves  the  necessary  information  on  the  top 
of  the  assertion  command  stack  for  use  when  the  matching  ENDLOOP 
directive  is  encountered. 

PRBVALUE  - new  procedure  in  JAVS-5 

This  procedure  handles  the  VALUE  assertions.  It  extracts  the 
variable  name  and  values  from  the  assertion  directive  and  generates 
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the  JOVIAL  code  to  make  the  check  and  output  an  error  message  if 
a violation  is  detected. 


G.  Logic  Diagrams 

The  upper- level  flow  of  the  JAVS  system  has  not  been  significantly 
affected  by  the  addition  of  the  assertion  directive  capabilities. 

H.  Flow  Chart  Diagrams 

This  section  includes  detailed  programming  flow  charts  for  each  of  the 
modules  that  was  added  to  the  JAVS  system.  Also  included  is  the  flow 
chart  for  PRBDIR,  the  only  procedure  with  major  flow  modifications. 
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Build  ASSCNT 
Declaration  Statement 


Build  ASSCNT 
Initialization  Statement 
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I.  Program  Constants 
Modified  constants: 

NJDIR  (in  LOOK)  - changed  from  11  to  16 

This  constant  indicates  the  number  of  directives  that  are 
recognized  by  JAVS . 

Table  Ll  (in  LOOK) 

Added  entries  to  items  JAVSDR  and  JAVSLN  for  each  of  the  new 
directives . 

New  constants: 

MAXSTCK  (in  PRBCHAIN,  PRBLOOP  and  common  ASSERT)  = 10 

The  size  of  the  assertion  stack  - indicates  the  maximum 
level  of  nesting  of  assertions 

J.  Program  Variables 
ASSERT  - Common  area  in  JAVS -5  component 

DCLASSCNT  - Indicates  whether  or  not  ASSCNT  has  been  declared  yet 
CSTKPTR  - Points  to  current  record  on  the  top  of  assertion  command 
stack 

Table  CMDSTK  - Assertion  Command  Stack 

VARNAME  (Hollerith  24)  - Index  variable  name 

LENNAME  - Length  of  string  in  VARNAME 

NEXTVAL  (Hollerith  48)  - Arithmetic  expression  for  next 

index  value 

LENNEXT  - Length  of  string  in  NEXTVAL 

EXIT  (Hollerith  48)  - Exit  condition  from  assertion  loop 
LENEXIT  - Length  of  string  in  EXIT 

LABEL  (Hollerith  6)  - Generated  label  put  at  the  head  of  JOVIAL 
code  for  assertion  loop 
LENLABL  - Length  of  string  in  LABEL 

ELABEL  (Hollerith  6)  - Generated  label  put  at  the  termination 
of  JOVIAL  code  for  assertion  loop 
LENELBL  - Length  of  string  in  ELABEL 

MINCNT  (Hollerith  24)  - Minimum  of  record  COJNT  range 
LENMIN  - Length  of  string  in  MINCNT 

MAXCNT  (Hollerith  24)  - Maximum  of  record  COUNT  range 
LENMAX  - Length  of  string  in  MAXCNT 

PRBCHAIN  (MODULE,  STMT)  - Procedure  in  JAVS -5  component 
ASSLEN  - Holds  the  length  of  the  string  in  ASSTXT 
ASSTXT  - String  buffer  used  used  for  strings  that  are  built  from 
entries  in  the  current  statement  block 
FROM  - Marks  a position  in  the  current  SB. 

Usually  used  for  an  opening  parenthesis 
KEYWRD  - Marks  a position  in  the  current  SB. 

Used  for  marking  various  keywords 
MIDL  - Marks  a position  in  the  current  SB. 

Usually  used  for  the  range  operator 
MODULE  - Number  of  the  currently  active  module 
STMT  - Number  of  the  current  statement 
TO  - Marks  a position  in  the  current  SB. 

Usually  used  for  the  closing  parenthesis 
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TMPTXT  - Used  as  a temporary  string  buffer  when  calling  routines 
JUSTRT  and  LASTCH  to  determine  the  length  of  the  string 
in  ASS TXT 

TXTPTR  - Contains  the  character  count  for  the  statement  being 
built  in  TXTBUF 

PRBCHKL  (MODULE,  CHARS,  LENGTH  = NEW 'LENGTH)  - Procedure  in  JAVS-5 
component 

CHARS  - Length  of  string  to  be  added  to  TXTBUF 
LENGTH  - Length  of  current  string  in  TXTBUF 
MODULE  - Number  of  the  currently  active  module 
NEW 'LENGTH  - Length  of  the  string  in  TXTBUF  at  termination  of 
PRBCHKL 

PRBDCL  - Procedure  in  JAVS-5  component 
No  local  variables 

PRBENDC  (MODULE,  STMT)  - Procedure  in  JAVS-5  component 
ASSLEN  - Holds  the  length  of  the  string  in  ASSTXT 

ASSTXT  - String  buffer  used  for  strings  that  are  built  from  entries 
in  the  current  statement  block 
MODULE  - Number  of  the  currently  active  module 
STMT  - Number  of  the  current  statement 

TXTPTR  - Contains  the  character  count  for  the  statement  being 
built  in  TXTBUF 

PRBLBL  (STMT,  NO  = LABEL)  - Procedure  in  JAVS-5  component 

LABEL  - String  buffer  (length  = 6)  for  newly  generated  label 
NO  - One  digit  used  as  the  sixth  character  of  the  label 
STMT  - Number  of  the  current  statement 

PRBLOOP  (MODULE,  STMT)  - Procedure  in  JAVS-5  component 
ASSLEN  - Holds  the  length  of  the  string  in  ASSTXT 
ASSTXT  - String  buffer  used  for  strings  that  are 

built  from  entries  in  the  current  statement  block 
FROM  - Marks  a position  in  the  current  SB. 

Usually  used  for  an  opening  parenthesis 
KEYWRD  - Marks  a position  in  the  current  SB. 

Used  for  marking  various  keywords 
MIOL  - Marks  a position  in  the  current  SB. 

Usually  used  for  the  range  operator 
MODULE  - Number  of  the  currently  active  module 
STMT  - Number  of  the  current  statement 
TO  - Marks  a position  in  the  current  SB. 

Usually  used  for  the  closing  parenthesis 
TXTPTR  - Contains  the  character  count  for  the 
statement  being  built  in  TXTBUF 
VARLEN  - Holds  the  length  of  the  string  in  VARTXT 
VARTXT  - String  buffer  that  is  used  to  save  the 

variable  name  that  is  extracted  from  the  assertion 

PRBVALUE  (MODULE,  STMT)  - Procedure  in  JAVS-5  component 
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ASSLEN  - Holds  the  length  of  the  string  in  ASSTXT 
ASSTXT  - String  buffer  used  for  strings  that  are 

built  from  entries  in  the  current  statement  block 
FROM  - Marks  a position  in  the  current  SB. 

Usually  used  for  an  opening  parenthesis 
MIDL  - Marks  a position  in  the  current  SB. 

Usually  used  for  the  range  operator 
MODULE  - Number  of  the  currently  active  module 
RPAREN  - Marks  the  position  of  the  right 

parenthesis  surrounding  the  list  of  values 
in  the  assertion 

STMT  - Number  of  the  current  statement 
TO  - Marks  a position  in  the  current  SB. 

Usually  used  for  the  closing  parenthesis 
TXTPTR  - Contains  the  character  count  for  the 
statement  being  built  in  TXTBUF 
VARLEN  - Holds  the  length  of  the  string  in  VARTXT 
VARTXT  - String  buffer  that  is  used  to  save  the 

variable  name  that  is  extracted  from  the  assertion 


K.  Inputs 

All  inputs  are  in  the  same  form  as  before.  All  inputs  that  were  pre- 
viously recognized  are  still  valid.  The  effect  of  this  modification  has 
been  to  expand  the  set  of  directives  that  JAVS  would  accept  as  input. 

The  new  JAVS  directives  that  are  acceptable  as  input  have  syntaxes  as 
defined  below: 

".CHAIN  ((variable  name))  1NIT  ((arith.  expr.))  NEXT 
((arith.  expr.))  END  ((boolean  expr.))  [EMPTY 
((boolean  expr.))]  [BOUNDS  ((range))]  [COUNT 
( (range))  ]" 

".ENDCHAIN" 

".ENDLOOP" 

".LOOP  ((variable  name))  ((range))  [EMPTY  ((boolean  expr.))]" 

".VALUE  ((variable  name))  [NOT]  ((list  of  values  and/or  ranges))" 


L.  Output 

All  output  generated  by  the  additions  to  JAVS  takes  the  form  of  that 
which  is  generated  by  the  unmodified  version  of  JAVS.  Like  the  origi- 
nal JAVS  computational  directives,  each  new  assertion  directive  causes 
the  generation  of  JOVIAL  code  which  is  inserted  into  the  probed  text. 

All  error  diagnostics  are  output  using  the  standard  ERROR  procedure  so 
their  form  is  also  consistent  with  that  of  the  error  messages  of  the 
unmodified  JAVS. 

M.  Error  Messages 

ASSERTION  STACK  OVERFLOW 

There  is  an  overflow  condition  on  the  assertion  command  stack.  The 
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number  of  nested  LOOP  and  CHAIN  directives  exceeds  the  permissable 
limit.  This  limit  is  defined  as  MAXCSTK  (=10)  in  procedures 
PRB CHAIN  and  PRBLOOP  and  in  common  ASSERT.  Error  detected  in  pro- 
cedure PRB CHAIN  or  PRBLOOP. 

ASSERTION  STACK  UNDERFLOW 

There  is  an  underflow  condition  on  the  assertion  command  stack. 

For  the  ENDLOOP  or  ENDCHAIN  directive  being  processed,  there  has 
been  no  matching  LOOP  or  CHAIN  directive.  Error  detected  in  pro- 
cedure PRBENDC. 

CHAIN  ASSERTION  ERROR  - NO  END  FIELD 

No  END  field  specified  for  a CHAIN  assertion  directive.  Error 
detected  in  procedure  PRBCHAIN. 

CHAIN  ASSERTION  ERROR  - NO  I NIT  FIELD 

No  INIT  field  specified  for  a CHAIN  assertion  directive.  Error 
<V*’ected  in  procedure  PRBCHAIN. 

CHAIN  ASSERTION  ERROR  - NO  NEXT  FIELD 

No  NEXT  field  specified  for  a CHAIN  assertion  directive.  Error 
detected  in  procedure  PRBCHAIN. 

N.  Operating  Instructions 

There  are  no  new  special  operating  instructions  to  go  with  these  modifi- 
cations . 
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JAVS  Modification  Listings 


This  section  contains  the  partial  compilation  listings  for  the  modified 
version  of  JAVS.  JAVS  is  a large  system  which  contains  several  hundred 
different  modules.  It  is  therefore  impossible  to  include  here  the  listings 
for  each  of  those  modules.  What  is  included  are  listings  for  every  new  pro- 
cedure and  every  procedure  that  was  modified.  The  listing  of  the  compool 
that  contains  the  added  common  area  is  also  included.  For  a description  of 
the  other  modules  in  the  system,  refer  to  [17]. 
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APPENDIX  V 

This  section  contains  the  output  listings  from  an  example  run  of  the  modi- 
fied JAVS.  The  example  was  designed  to  illustrate  the  use  of  our  new 
assertion  constructs  and  the  use  of  JAVS  as  a preprocessor  for  those  con- 
structs. The  program  does  nothing  and  in  fact  contains  only  one  executable 
statement.  (If  there  are  no  executable  statements,  JAVS  ignores  the  module 
entirely.)  The  logical  data  structure  that  the  assertions  are  being 
applied  to  is  a two-dimensional  array  of  records.  More  specifically,  it  is 
a sequential  list  of  linked  lists  of  records.  Thus,  to  access  each  record, 
a CHAIN  loop  is  nested  within  a LOOP  loop.  Within  the  inner  loop,  the 
VALUE  and  NOT  VALUE  assertions  are  each  demonstrated.  For  illustrative  pur- 
poses, all  the  possible  optional  clauses  are  used  with  each  of  the  direc- 
tives . 

The  first  job  activity  is  the  JAVS  basic  source  analysis  during  which  the 
JAVS  library  for  this  particular  program  is  built.  In  the  next  activity, 
JAVS  is  run  again  to  generate  the  probed  text  from  the  original  source  and 
the  directives.  The  third  activity  is  a compool  compilation  that  is  neces- 
sary for  compilation  of  the  instrumented  source  code.  The  last  activity 
demonstrates  the  compilation  of  the  probed  text. 


85 


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXIXXXXXXIXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXIXXXXXXXX 


72 


0320'  S LIMITS  fiO, 58k. -5K. 20000 

0021'  $ FILE  o3,x3k,10R 

0022*  S FILE  0H.XUR.2L 

0023  Si  P R K F L OI.R.R.BFCBKWOe/LlBRXRIJ 
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MISSION 

of 

Rome  Air  Development  Center 

PAVC  plan*  and  executes  ice*  coach,  development,  test  and 
selected  ac quisition  programs  In  support  of  Command,  Control 
Communications  and  Intelligence  (C3 1)  activities.  Technical 
and  engineering  support  within  areas  of  technical  competence 
is  provided  to  ESV  Program  0 ibices  ( POs ) and  other  BSD 
elements.  The  principal  technical  mission  areas  are 
communications,  electromagnetic  guidance  and  control,  sur- 
veillance o f ground  and  aerospace  objects,  intelligence  data 
collection  arid  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


